Cypress Integration Tests for Client-Side Routing

Like many web applications, CampSpots takes a client-side routing approach.

When an app uses client-side routing, it takes control of browser navigation away from the browser.

We need to make sure that someone who uses a keyboard or a screen reader has as good of an experience as a sighted mouse user does.

When a navigation link is clicked, the page should update accessibly. With traditional HTML navigation, the page refreshes and focus is reset to the top. There is also a configurable screen reader summary that reads out the page content.

For client-side routing with JavaScript, this functionality needs to be replaced somehow so users aren’t left wondering if anything happened after clicking a link. Keyboard focus should move somewhere, the page change should be announced, and the title should change.

In this section we’ll write some tests around routing to make sure we aren’t breaking anything by using React. Along the way, we’ll make decisions and talk about the trade-offs that come with client-side routing.

In terms of implementation, CampSpots uses Reach Router, from the same team behind React Router and Remix.

Reach Router is recommended for applications with only a few routes, and React Router for everything else. Ryan Florence, co-author of both React routing libraries, wrote a blog post explaining more.

🛠 Challenge: Preparing the Routing Tests

Inside of the exercise3 directory is an empty Routing.test.js file that needs to be prepared to test client side routing in CampSpots.

Your challenge is to write the starter for two tests: The first will test that the title changes when navigating to a new page.

The second test will test that the user is able to navigate to a new page using the keyboard.

Both of these tests will use the CampSpots homepage as its starting point.

Don’t worry about filling in the test logic yet— this is just creating the skeleton for the test file!

🛠 Solution: Preparing the Routing Tests

Here’s what the starting point of the Routing tests should look like:

describe('Routing', () => {
	beforeEach(() => {
		cy.visit('http://localhost:1234')
	})

  it('should have title changes', () => {

  })
  
  it('should change the page via keyboard', () => {
  
  })
})

describe('Routing', () => {
	beforeEach(() => {
		cy.visit('http://localhost:1234')
	})

  it('should have title changes', () => {

  })
  
  it('should change the page via keyboard', () => {
  
  })
})

Note: This video reflects an older project structure

Testing Page Changes

If you check out the index.html file in the repo, you’ll find that the <title> tag has been hardcoded to “CampSpots”.

Because we are working in a React application, we don’t have access to change stuff in the document head directly. All of the page-level components that we build will have the same hardcoded title.

Fortunately, there’s a library called React Helmet that allows us to manipulate things in the document head.

React Helmet is already installed as a dependency in the workshop repo and has been imported at the top of the page components:

// inside of page-home.js
import {Helmet} from 'react-helmet'

// inside of page-home.js
import {Helmet} from 'react-helmet'

Dynamically Set the Home Page Title

Inside of the HomePage component at page-home.js, we can add the <Helmet> component. The children inside of the component will look exactly the same as they would if we were writing the document head in plain HTML. Any tags we add will override what’s currently present in index.html.

Here’s an example of adding Helmet with the HTML title tag to the homepage:

// inside page-home.js
const HomePage = () => {
	return (
		<BodyClassName className="page-home">
			<>
				<HeaderPortal>
          <h1 className="visually-hidden">Camp Spots</h1>
          <Helmet>
             <title>Testing</title>
          </Helmet>
        </HeaderPortal>
		...

// inside page-home.js
const HomePage = () => {
	return (
		<BodyClassName className="page-home">
			<>
				<HeaderPortal>
          <h1 className="visually-hidden">Camp Spots</h1>
          <Helmet>
             <title>Testing</title>
          </Helmet>
        </HeaderPortal>
		...

The title change is then reflected in the browser:

Now that we know Helmet’s title update works, we can switch the title to say “CampSpots” for the homepage.

Note: This video reflects an older project structure

🛠 Challenge: Write a Test that Asserts the Title Changes

Write a test that asserts the title changes when visiting the About page on the CampSpots site.

Since the beforeEach is set up to start on the homepage, check that the title matches what you set in page-home.js.

Navigate to the About page, and assert that the page title has changed.

Follow the TDD approach– write a test that fails, then update your markup to make it pass.

Hint: If you get stuck, this Title syntax page in the Cypress API Docs will help!

🛠 Solution: Title Change Test

Here’s what my title change test looks like:

it('should have title changes', () => {
		// This test requires changes with React Helmet
    cy.title().should('eq', 'Camp Spots')

    cy.visit('http://localhost:1234/about')

    // test for title change
    cy.title().should('eq', 'About Camp Spots')
})

it('should have title changes', () => {
		// This test requires changes with React Helmet
    cy.title().should('eq', 'Camp Spots')

    cy.visit('http://localhost:1234/about')

    // test for title change
    cy.title().should('eq', 'About Camp Spots')
})

Thoughts on Client-Side Routing

The CampSpots app uses Reach Router which manages focus for you if you use its <Link> component.

But you may find that sometimes navigating around the app will jump focus part way down the page.

Honestly, client-side routing is hard to get right.

After doing my own testing and trying to make it work the way I wanted, I opted to not fully rely on client-side routing in this application.

One of the state issues I found when initially developing the CampSpots demo app was that using links from within the MegaNav would navigate the page but not close the menu. This alone wouldn’t be too difficult to fix but when combined with the focus jumping an undesirable place, client-side routing didn’t really feel worth it.

I’m still using Reach Router to render the pages but the navigation uses regular anchor tags instead of <Link> components.

If I were to ship CampSpots to production, I would also make it use server-rendered HTML instead of relying on client-side JavaScript to route and render pages.

That said, there definitely are some types of applications where using client-side routing can provide a better experience. If your app needs to maintain a lot of state without refreshing or deep links navigation to subviews, it probably would be a good candidate. But you’ll have to manage screen reader announcements and move focus yourself.

🛠 Challenge: Test Page Changes via Keyboard

Write a Cypress test that simulates using the keyboard to activate a link in the MegaNav. Assert that the page has changed.

🛠 Solution: Test Page Changes via Keyboard

There are multiple ways to do this but here’s my solution.

Because of the beforeEach block, I know that Cypress will navigate to the homepage successfully.

The first thing I’ll do is use cy.get() and pass in the selector for the first toggle button in the MegaNav. Then I’ll chain on calls to .focus() and .click() to open the first submenu.

Remember from earlier that this has the added benefit of ensuring that the MegaNav buttons are still focusable. Calling .click() has the same effect as hitting the Enter key once the button has focus.

With the menu open, I’ll use cy.realPress() and simulate hitting the Tab key to traverse the submenu. The first link in the menu will have received focus from the Tab key press, so I can call cy.focused().click() to click it and navigate to the Listings page.

In order to check if the page has changed, I’ll check that React Helmet has set the title to contain “Listings” like we set up earlier.

Here’s why my test looks like:

it('should change the page via keyboard', () => {
  // open meganav
  cy.get('[data-testid="megamenu-section1"]').focus().click()

  // tab into nav
  cy.realPress('Tab')

  // click first nav item for /listings page
  cy.focused().click()

  cy.title().should('contain', 'Listings')
})

it('should change the page via keyboard', () => {
  // open meganav
  cy.get('[data-testid="megamenu-section1"]').focus().click()

  // tab into nav
  cy.realPress('Tab')

  // click first nav item for /listings page
  cy.focused().click()

  cy.title().should('contain', 'Listings')
})

When I run the test in Cypress, it passes as expected: